Whether accessing content through a public or private portal, a content manager may design the content as static, dynamic, or a mix of static and dynamic. As the name implies, the content of a static web page remains static and does not change unless you replace it manually with fresh content. Apart from ease of design, static web pages are much less demanding on resources than that of dynamic web pages. As a result, static web pages load faster and are easy to locate over a diverse network.
On the other hand, dynamic web pages have content that is stored in a database (server) and rendered as web pages or portlets within web pages when requested by website users. The design of such web pages can be customized to individual users or group of users using attributes, business rules, etc. That is, the web pages and more particularly the portlets can be filtered, depending on the access level of the user using, for example, attributes, business rules, etc. Thus, the database-driven dynamic websites are useful where content changes frequently, but requires immense resources to maintain the content.
In a large portal application with numerous content selection rules, selecting the right pieces of content for the user's authorization, attributes, and business rules becomes very complex. Also, in web service distribution applications, the ability to control access to groups in a given time period or using other constraints is very resource intensive.
By way of one example, a retail store website may offer many different types of promotions each targeted to a specific category of users. These promotions may include, for example, a 10% discount to those users having a line of credit with the retail store, while another type of promotion may be a 5% discount on selected items to those users having made a purchase from the retail store within the last 10 days. These promotions may be rendered as portlets within a web page, itself.
To access the content, all pieces of the content (all portlets) for each and every scenario associated with the request must be uploaded to the end user application where it is processed. More specifically, regardless of the business rules, attributes and/or user's level of access, all of the pieces of content associated with the promotion (or other portlet information) is uploaded to the end user application, where it is processed. Only after the content is processed by the end user application can the relevant portlet be accessed by the end user.
The processing that takes place at the end user application, though, places a heavy burden on the end user application. Also, since the content may be coded at different repositories, e.g., servers, it makes it more difficult to manage such content; that is, it is not possible to efficiently manage the content at the end user application. For example, content can remain exposed even though the content has expired.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.